Originally by: CCP Stillman

---

Originally by: Vessper

---

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.

---

Good catch, I'll discuss with Elerhino about changing that to be more explicit!

Thank you :)

---

Originally by: CCP Stillman

---

Originally by: Johnathan Roark

---

Edited by: Johnathan Roark on 22/07/2011 04:14:25
How long will both systems work, and will we still be able to make the old style of keys?

Any chance of adding a semi-static api with with the mask for convenience?

Are the keyIDs unique? any risk of two players having two of the same keyID? I'm guessing unique since my first one was 245.

---

1. We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.
2. Do you mean something like /api/calllist.xml.aspx? That gives you the access mask for each call, so if I understand your question, that should do what you're asking for
3. They're unique, yes.

---

Originally by: Vessper

---

Originally by: Johnathan Roark

---

Originally by: CCP Stillman

---

Originally by: Vessper

---

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.

---

Good catch, I'll discuss with Elerhino about changing that to be more explicit!

Thank you :)

---

My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.

---

As I mentioned earlier, it's not that particular API's place to determine what characters are on what account, but only to state the ability of the key presented. I guess you would need the Characters.xml.aspx to continue it's previous role and provide full disclosure of alts. In which case, I suggest that the API be moved to an optional one and allow users to decide whether to disclose this information in their APIs.

---

Originally by: Somerset Mahm

---

The wiki still has AssetList being a 23-hour expiry, but it's 6-hour now.

Looking really good so far.

---

Originally by: Dragonaire

---

I've been trying some things with the APIs and thought I'd share what I've found and make a sugestion on a change to account/APIKeyInfo.xml.aspx which would be useful.

First something I've notice is none of the corp APIs now need characterID which makes sense since all corporation type keys are per character unlike the old ones.

If you use a single character key with char APIs you also don't have to use characterID with them but if you use one made to work for all characters you do have to include characterID parameter in the query so API knows which one you want.

Given the above and the fact that multiple corp keys don't really make sense when you think about it I think it would be nice if the type attribute in APIKeyInfo would return "All", "Character", or "Corporation" instead of just "Character", "Corporation". Could that be done? I think it would be an easy change to make server side and could greatly simplify parsing and using it in applications because there really are three types of keys now and they may need different handling at times.

Anyway thought I'd share the above and see what everyone else thinks.

---

Originally by: Johnathan Roark

---

My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.

---

Originally by: Vessper

---

Edited by: Vessper on 29/07/2011 20:56:35

Originally by: Desmont McCallock

---

So what needs to be fixed is:
- Returned characterID info of APIKeyInfo call for all characters. Fixed.
- Set AccountStatus as private information call (update calllist with given accessMask). Not fixed.
- Switching results of CharacterInfo call between public and private info group. Not fixed.
- Revise returned ship info of CharacterInfo call. Not fixed.

---

As far as I can tell, the AccountStatus API has been moved to a private character API with an access mask of 33554432. In addition, the new Contract APIs have also been included (both character and corporate) and masks added. I've not tested these so no idea if they actually work as planned.

---

Originally by: Desmont McCallock

---

Edited by: Desmont McCallock on 30/07/2011 07:27:13

Originally by: Vessper

---

As far as I can tell, the AccountStatus API has been moved to a private character API with an access mask of 33554432. In addition, the new Contract APIs have also been included (both character and corporate) and masks added. I've not tested these so no idea if they actually work as planned.

---

By the time I was writing that lines it was either not there or I missed it completely. Never the less I updated my post and will whenever something in the list get fixed.

---

Originally by: Desmont McCallock

---

Edit: I could still query the AccountStatus call although I had the call restricted.
So, we are adding another thing on the TO BE FIXED list.

Originally by: Johnathan Roark

---

I no longer see a way to tell the difference of a key for an account that has one character on it or restricted to show one character. This will either force corporations to require all character slots are full for recruitment and/or screenshots of character selection.

---

I was too concerned about that and unfortunately the "screenshot" thingy is going to come back.

On another note, whenever I go update my api key info a new code is generated. CCP Stillman, can you have a look at that?

Edit2: Shouldn't the 'Contracts' call be at the "Account and Market" group (I think they are market related after all) ?

---

Originally by: Desmont McCallock

---

Originally by: Hel O'Ween

---

Originally by: Johnathan Roark

---

Edited by: Johnathan Roark on 30/07/2011 20:09:38
Btw, what is the point of the characters call now? I suggest depreciating it and remove it when you remove generation of old style keys.

---

Isn't it the same as before? Given an "All Chars" key, you retrieve the chars info (=charID, charName etc.) associated with that key.

---

Johnathan has a point as APIKeyInfo and Characters calls return the same data with the exception that APIKeyInfo returns also the "accessMask".

Yes the problem would be solved if each call had its unique 'accessMask' but the question that pops up is "how high will that number go?". Is 64bit enough or we will end up with 128bit?

---

Originally by: Vessper

---

Originally by: CCP Stillman

---

APIKeyInfo.xml.aspx contains a list of all characters you can query

---

I think what most people are trying to get at is a simple way of finding ALL characters on the account, irrespective of whether the API key is for one or all characters. If the API key is set up for access to the data of only one character, APIKeyInfo.xml.aspx only shows the one character, as does Characters.xml.aspx.

Two possible ways this could be done:

1. Characters.xml.aspx shows all characters on the account, those that are accessible by the API key and also those that aren't.
2. APIKeyInfo.xml.aspx (or Characters.xml.aspx for that matter) adds another field indicating the number of characters created on the account. This would show if there are any additional characters but not disclose their IDs or names.

Personally, I'd prefer the first option but whatever is easier.

Also, confirming that clicking the update link on the API Key index page resets the vCode to some random string, which it clearly shouldn't.

---

Originally by: Sable Blitzmann

---

Did you ever fix the permissions? I remember when the dev blog went up, people with roles in-game were not able to get the same information from the new corp APIs. IE: Directors accessing member tracking and killmails for the corp, accountants not able to access the corp wallet API, among other things. These were restricted to only the CEO.

If these haven't been ironed out yet, THEY ABSOLUTELY MUST BE before launch. =)

---

Originally by: Desmont McCallock

---

Edited by: Desmont McCallock on 06/08/2011 12:54:38

In line with Dragonaire's thoughts, I think the solution lies already there in the CAK structure. Returning values of "type" could be the exact variables you set when you create the key, aka 'All', 'Character', 'Corporation'.
So when "type" returns something else than 'All' it means that the key is a character restricted one.

---

Originally by: Desmont McCallock

---

Edit: Btw, I think the 'key' row should also return the accountID (userdID) to make the account tying of multi api keys possible.

---

Originally by: CCP Stillman

---

Originally by: CCP Stillman

---

Originally by: Johnathan Roark

---

I would rather APIKeyInfo have type="all". option 1 would reverse one of the biggest points of this new system.

My biggest concern with cak is telling if a key is for all characters or just one. Right now, an account with ONE character on it looks EXACTLY the same as a key restricted to one character.

---

Oh, I understand now.

Consider it done

---

The type attribute now returns either "Account", "Character" or "Corporation" depending on how it's made. I hope that fixes the issue.

---

Originally by: CCP Stillman

---

Originally by: EVEVERIFY Cashier

---

Originally by: CCP Stillman

---

I don't wanna promise too much. But...

---

---

Here it is.

---

Originally by: Dragonaire

---

So I thought of something while looking at the XML for APIKeyInfo to make a new XSD schema for it. With all the changes from custom keys and added APIs etc shouldn't the version on

<eveapi version="2">

be changed to '3'? It probably could have been changed before now but with as big of change as custom keys is I think it's important to reflect that in the version.

---

Originally by: Risingson

---

Originally by: CCP Stillman

---

Originally by: Risingson

---

Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

---

What info exactly? I can't reproduce that :(

---

reproduction steps: create a key for public char info only and use it to get your character info.

when i try:

keyID 428 got access mask 16777216 for CharacterInfo public only.

http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407

info it should not contain but does are accountBalance ,skillPoints, lastKnownLocation, etc

---

Originally by: Desmont McCallock

---

Edited by: Desmont McCallock on 22/08/2011 14:37:52
We are almost one week away from CAK system deployment and IMO at this point we have a system that functions rather than a functional system.

Although many issues have been addressed, there are still some that persist and others that by solving them, would make our lives (as 3rd party app devs) much easier.

Let me explain.

Issues already spotted but still haven't been solved.

Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa.
Solution: Reverse the results of eah call.

---

Originally by: Desmont McCallock

---

Issues that by solving them would make 3rd party app dev-lives easier.

Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).

Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.

---

Originally by: Desmont McCallock

---

Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.

Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.

---

Originally by: Desmont McCallock

---

Originally by: Risingson

---

Originally by: Desmont McCallock

---

The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.

---

If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.

---

At this point, the way CAK is configured, by looking into the APIKeyInfo call and according to the "type" value (aka "Account", "Character", "Corporation") of the key row, one is able to determine if the key provided is for the entire account (therefore exposes all characters in an account) or is restricting the access to a particular character (meaning there are more characters in the account and the user prefers to hide them).

My request has nothing to do with what you are referring rather is a request to provide us with additional info to bound multiple API keys to an account.

---

Originally by: MJ Maverick

---

So is this an added extra or replacing the Limited API completely?

If it's replacing it completely I don't see how EVEOTS can survive, thanks. The system needs to have permission to check alliances/corporations and all characters on the account. Along with tickers, corp IDs, alliance IDs etc etc...

So I'm now going to have to ask the user to create a specific API for me. Politely asking "please can you not hide your red alt character Mr Spy". This is all going to add up to my simple registration steps becoming a bastion of complicated and confusing errors for the users.

As the only way to check if a resource isn't there (hidden) is to generate an error and many can be generated one after another and that's just for one person registering then any server using EVEOTS will be blocked from talking to the API server within just a couple of registrations... The whole system comes to a halt and the system to get your guys registered on comms comes to a grinding halt.


So in short Stillman. This idea seems like a great option but please, please, I implore you; do not remove the Limited API. People won't be willing to hand over a FULL API so there is no substitute for keeping the Limited API that can't be messed with as an option.

- Mav

---

Originally by: Zifrian

---

Is there a way to see Corp Assets from a character key? I see that the keys are separated into corporation and character but in the old API system, with a full key you could see corporation assets when using a character that was in the corp.

I can totally see how you want to keep asset information restricted to directors, but the reason this is useful is for industry programs that allow scanning of corp blueprints for use. Many industrialist characters make their own corps and share bps with multiple alts with the use of the corp. Industrial corps do this as well for multiple members and if a user wants to use a program that calculates data on manufacturing from a corp blueprint, they won't have access to this now. Even the director of the corp will have to enter a separate key to scan for corporation blueprints. I guess the director could share this key for use by members, but that is not ideal for many reasons. Plus, it creates a bit of programming work to separate.

Is there something I'm missing here that gives this functionality or is there a workaround to get this functionality? SOL?

---

Originally by: Xander Hunt

---

Some sort of call back *PLEASE* for that INSTALL link.

I'm loving the eve:// for mobile phones, but for desktop or web apps, the install should be able to "link back" to whatever made the call. Aura (For Android) works BRILLIANTLY with this.

For a web interface, it'd be a snap. My web application would provide POST data to the API server with a URL to which is should send data back to when clicking INSTALL. When the user clicks the INSTALL, the install HREF points http://myserver.com/path/installkey?keyID=4325&vCode=JkujoankjnAASL879KN where red is what we provide in the POST and yellow is what you return to us.

I'm scratching my head as to how this could be streamlined for desktop apps, and it may just boil down to a user having to copy/paste. But a desktop app is a different beast compared to a web interface, in that the web interfaces SHOULD be able to talk with each other more seamlessly.

---